HTTP的演變：
HTTP1.0 → HTTP1.1加入了兩個設計
• Pipeline Request - 當Request發送出去後不用等下面的Response回來， 如果網頁還有很多資源，可以繼續且連續的發送Request，這樣提升了效能
• Cache Proxy (快取/緩存 代理) - 上次提到Response裡有一個Last-Modified，讓瀏覽器端和代理伺服器可以做快取的動作，這同樣也提升了效能

Netscape瀏覽器是FireFox的前身，它加了一些功能
• Cookie - 讓伺服器把某一些資訊存在瀏覽器端，如：網路購物的購物車就是此應用
• SSL/TLS - 加入加密功能，因為Web是TCP，所以它主要用SSL和TLS
• JavaScript - 原本它的程式都在伺服器端執行，現在改為把一些可以執行的程式跟著網頁內容一起送到瀏覽器端，所以就有一部分能在瀏覽器端執行，一部分在伺服器端執行，順著應用做不同的調整

這三個功能讓HTTP變得很有彈性，也讓Web平台從內容平台變成應用軟體平台，但此時HTTP仍有些效率、功能、安全的問題，因為用量太大、主從式的Server完全被動，且沒有一定要求使用SSL，後來經過SPDY的實驗正式產生HTTP/2
• 向下相容HTTP1.1 - 程式不需做修改，作業系統也不需修改，讓瀏覽器與伺服器來做，傳送的資料格式做一些修改
• 多工 - 瀏覽器可以同時發出很多Request，能設定優先順序
• 推播(Server Push)與提示(Server Hint) - 伺服器端可以對瀏覽器端發出推播或提示訊息
• Header編碼壓縮 - 原來Header都是文字，壓縮後訊息量就能減少
• 強制使用SSL加密

CoAP(Constrained Application Protocol)：
較簡單的輕量級協定，跟HTTP一樣都是主從式運作，主是指伺服器，它永遠是提供資源、服務的角色；從是指瀏覽器，它永遠是取得資源、服務的角色。CoAP也能進行GET、PUT、POST、DELETE的動作，它是物聯網中資源受限的應用層協定，環境不像HTTP那麼好，它的傳輸層協定為(Port5683)的UDP，使用DTLS加密，感測的終端裝置可設為CoAP Server來推播感測資料。它的服務品質(Quality of Service, QoS)可分為兩種，Confirmable訊息要求接收端收到訊息時要回覆ACK(acknowledge)，如果沒有收到ACK就會再傳送一次，透過這種方式來保證資料能送到；有些應用不需要可以使用Non-Confirmable訊息。

物聯網常用MQTT(Message Queuing Telemetry Transport)：
發訊息時為發布者的角色，取得訊息時為訂閱者的角色，它是一種publisher-subscriber model的模式。因為無法在網路上做全部的廣播，這樣會有頻寬、效能、安全等問題，所以中間一定會有一個broker或代理人，在物聯網或裝置上就是一個閘道器。它的傳輸層為(Port1883)的TCP，但與HTTP不同屬於輕量級協定，物聯網閘道就可設為MQTT中介。它的服務品質(Quality of Service, QoS)可分為三種，至多一次指資料可能丟失但最多只送一次，應用在不太關切資料，下次還會傳的情形，如：環境感測；至少一次旨在訊息不會丟失，但可能會重複傳送；剛好一次適合用在對次數較嚴謹的情況，如：計費系統

參考資料
https://www.youtube.com/watch?v=IbTUVFdD_bI&list=PLdSWxzxDhd3HcpDDa8svbBrD9qRQj39bW&index=2